In 2022, I left Google in search of a sustainable approach to open source maintenance. A year later, I was a full-time independent professional open source maintainer. Today I’m announcing the natural progression of that experiment: Geomys,[1] a small firm of professional maintainers with a portfolio of critical Go projects.
I’m joined by Nicola Murino, who's been maintaining golang.org/x/crypto/ssh for us since last summer[2], and by Dominik Honnef, the maintainer of Staticcheck and Gotraceui. They are now Geomys’ first ✨ Associate Maintainers. ✨ The team is completed by Matilde Dal Zilio, our Administrative Director who's been helping make this journey possible from the beginning.
Geomys launches with a robust portfolio of popular, foundational open-source Go projects:
- the
crypto/...andgolang.org/x/crypto/...packages in the Go standard library, co-maintained by me and the Google Go team - the
filippo.io/...crypto packages, including filippo.io/edwards25519 - x/crypto/ssh, the Go SSH implementation that runs many CI and deployment systems, maintained by Nicola
- Staticcheck, the high-signal low-noise static analyzer enabled by default in vscode-go, maintained by Dominik
- Gotraceui, a tool for visualizing and analyzing Go execution traces, maintained by Dominik
- bluemonday, the popular HTML sanitizer[3]
- age, the file encryption tool, library, and format
- mkcert, a tool to generate local development certificates
Every company that was previously a client of mine is now a Geomys client, paying the same monthly retainer for the professional maintenance of their critical dependencies, and for direct access to the expertise of maintainers. What’s changed is that they are now supporting more projects, and have access to more maintainers.
How we got here
I started with a rather non-consensus hypothesis: companies want to pay for their critical open source dependencies, but most projects are not selling them a legible way to do so. The last year has shown I was definitely onto something: I have signed four more major clients, and lost only one.[4]
The model and pitch also came into clearer focus. Truly, it’s simple: if you’re betting your business on a critical open source technology, you
- want it to be sustainably and predictably maintained; and
- need occasional access to expertise that would be blisteringly expensive to acquire and retain.[5]
Getting maintainers on retainer solves both problems for a fraction of the cost of a fully-loaded full-time engineer. From the maintainers’ point of view, it’s steady income to keep doing what they do best, and to join one more Slack Connect channel to answer high-leverage questions. It’s a great deal for both sides.
There were more lessons learned, which can be summarized as “yup, these are enterprise sales, checks out”, and “advisor is a better word than consultant but still not perfect”, and “we sorely need to build standard contract language”. I will write these up soon, but if you’re impatient you can watch my recent FOSDEM talk.
Still, even if the path may look straightforward in hindsight, it’s a new model and materializing it has been a challenge. I am incredibly grateful to my clients for believing in it and for making it work with me.
What next
Now, where do we go from here? How do I help this grow?
One way is by making it easier to do what I did, so that others can replicate it. Part of the point of doing it myself was clearing a path and making the life of future professional maintainers easier. That’s still part of the plan, but for “open source maintainer” to graduate to a mature profession, it needs to also be accessible to folks who can’t or don’t want to take on that risk, uncertainty, and extra workload.
From the onset, I envisioned small firms of professional maintainers with thematic portfolios, accommodating diverse maintainers and project sizes, just like the specialized firms of other professionals. I am now ready to try and build one.
I can tell you when I made up my mind, actually. It was with this message from a client:
I noticed that there are two critical Go projects that we (and many others) rely on are not very actively maintained. […] Do you have any interest to become owners/co-maintainers of these projects? We'd be interested in sponsoring the maintenance, security audit, and hardening of those projects.
They trust us to maintain open source projects as a reliable team of professionals, and they understand the importance of keeping their critical dependencies healthy, so they want us to get involved in more. That's what we'll do.[6]
Geomys
Alright, so how does Geomys work?
Clients still pay a fixed monthly retainer to ensure the professional maintenance of the whole portfolio, and to get access to the expertise of all of Geomys’ maintainers. It’s a package deal because in my experience it’s nearly impossible to rigorously apportion value to specific projects, and it would slow down the sales process. Also, it risks penalizing smaller projects, and I want every project in the Geomys portfolio to be sustainably funded. Instead, clients just have to decide if the portfolio as a whole is worth the sticker price.
Associate Maintainers get a stable, guaranteed income—significantly higher than what GitHub Sponsors generates—and a cut of future retainer revenue growth. There’s no formula, we negotiate and figure out numbers that make the Associate happy and that are sustainable for Geomys, based on the project and on how much time the maintainer wants to dedicate to them. I expect the percentage value of the revenue share to go down over the years, rewarding those who take the most risk by joining early.
The expectations of Associates are primarily to keep doing what they’re doing: they are already experienced maintainers who know how to keep their projects healthy, now with the freedom and peace of mind of sustainably dedicating proper part-time or full-time attention to them. We want them to work on their schedule, and in their own way. I don’t wish to micromanage anyone, nor would I be particularly good at it. I like to think of Geomys as enabling maintainers to do what they already do well.
We only ask that they join the Geomys Slack Connect channels of interested clients, and ideally that they work with our technical writer to publish the occasional article about what they’re up to. Geomys is not meant to overshadow the Associates’ profiles. Quite the opposite: its brand is as strong as the combination of those of all its maintainers.
Speaking of technical writers, Geomys covers and consolidates the cost of support staff, providing maintainers access to resources that would be hard to justify if working solo. Administration, legal, comms, and importantly, the sales process are all handled as a unit.
No copyright assignment. No locked in term. No GitHub ownership transfer. If we decide it’s not working, we go our own ways. Who knows, maybe one day our associates will spawn their own firms, like it happened with early information security consultancies.
We’ll grow slowly and organically, by recruiting Associate Maintainers when it makes sense (and we can sustainably afford it) and by adopting projects that are a good fit for the portfolio theme. We are taking no investments: this is all financed by my existing cash flow. Don’t get me wrong, I think this is going to make me money in the long term: as we grow we’ll appeal to more and more clients, and the marginal effort required by each client is sub-linear. However, Geomys will probably never be a unicorn, and after cutting in Associates I doubt I’ll get startup-founder rich. That’s ok, that was never the goal.
Speaking of which, Geomys will always focus on Go. It’s not aiming to become Open Source Maintainers, Inc., a one-stop shop for maintenance services, just like you largely don’t go to Lawyers, Inc. for all your tax, immigration, criminal, and human rights law needs. That ensures our portfolio is highly relevant to our clients, and avoids diluting access too much: having an account manager join your Slack is not the same thing as having the actual maintainers. It also lets us concentrate on what we are all actually experts in. I hope others will set up similar firms in other ecosystems, and I will be here to help them however I can.
We’re just getting started and we’re still learning, so I expect things will change as we get more experience. Whatever final form it will take, I believe this is another step down the road of making “open source maintainer” a mature profession, and I’m really excited to find out where it leads.
You can follow along by subscribing to Maintainer Dispatches, which will soon become Geomys Dispatches. You can also follow us on Bluesky at @geomys.org or on Mastodon at @geomys@abyssdomain.expert. If you want to reach out, you can email the hi@ alias of geomys.org.
The picture
The plan for Geomys came together while I was driving the Centopassi, the 1600km-in-three-days motorcycle competition I told you about in the last Cryptography Dispatches issue. The intercom battery had ran out, so I was alone with my thoughts for a couple hours.[7] This is the view that opened up right after that stretch of mountain roads. (Also, the Geomys logo is inspired by a different town we passed at the beginning of that segment!)
It’s the scientific name of a genus of gophers! ↩︎
Nicola’s work on x/crypto/ssh has been a success, both for the project and for the business, even before Geomys was on the radar. We’ll talk about what he’s been up to soon. ↩︎
This is news, too! We inherited it from the original author, who was ready to move on after serving the community for ten years. I volunteered to take over before I ever even thought of Geomys, because of how critical the package is in the Go ecosystem, but it’s a perfect fit for the portfolio. For now I am responsible for it, but we’re working to engage the perfect longer-term maintainer. More on this soon! ↩︎
It didn’t even have anything to do with the services, we worked together very well for as long as practical, and parted on great terms. I would not have bet on such a low churn rate. Since this is a footnote I feel safe enough to say that despite knowing things were working out and clients looked happy, there were days I kinda braced for everyone to cancel at the one-year mark or something. ↩︎
Imagine you want to build specialized expertise in the functioning of an open source project internally. Even assuming you have enough interesting work to recruit and retain the right people, you will need to hire at least two Senior Software Engineers, or you lose all institutional knowledge as soon as one leaves. Really, to avoid refocusing on hiring upon a departure, you need three. You’re looking at north of a million dollars per year, fully loaded. It’s a classic build vs. buy. When you frame it like that, my contracts are cheap. ↩︎
We’re not ready to announce our plans for those projects, but we are talking with industry experts to rewrite part of them, to improve security and reduce the maintenance burden, and will reach out to the current owners to figure out next steps. It will make for an excellent case study and hopefully we’ll get to write about it! (That makes it four promised upcoming topics. I know. Don’t worry, the technical writer starts on the 15th.) ↩︎
Or, rather, my teammate Harry decided I needed some time to think, and told me the intercom was still charging. He was spot on. ↩︎